【レポート】コンテナとAIで感動を！データ駆動型サービスの為の生きたプラットフォーム構築 #AWSSummit

こんにちは、崔です。 AWS Summit Tokyo 2019 初日のL1-01のセッションである 「コンテナとAIで感動を！ データ駆動型サービスの為の生きたプラットフォーム構築」のレポートをお届けします。 パイオニア様によるカーナビサービスへのEKS/SageMakerの導入のお話です。

カーナビの通信サービスの歩み

パイオニアを取り巻く環境の変化と課題

２つの大きな環境変化がある。 カーナビに対抗して、Webサービスやスマホアプリが競合になってきた 年単位での変化では要望に応えられない

また、BtoB向けのサービスが増えてきている 利用増加に伴うリソースの増加が問題になってきている

変化に対応するための課題

• アプリケーションリリースサイクルの短縮
• 環境に依存したソースコード
• お客様へ提供できる価値の明確化　→　Amazonが提供するデジタルイノベーションプログラムを利用
• 開発と運用の分離
• サービスを駆動させる

デジタルイノベーションプログラムとは

アマゾンにおけるイノベーションの考え方やフレームワークを参考にしたもの

プラットフォームの全体像

今までのプラットフォーム

• IaaS主体
• エンタープライズ対応のKubernetesコンテナプラットフォームを利用
• 柔軟なりソース調達が難しい
• ビルド環境が分離

データ駆動型サービスとは

• 継続的な可視化からの気付き
• 何時でもHotな分析環境
• モデルデータの継続的な更新、アプリケーションの継続的デリバリー

Amazon EKSへの移行とオペレーションの改善

今までのコンテナ環境

ベアメタル環境でKubernetesを運用　スケーラブルではない 複数のサービスが稼働 CI/CDは簡易的に用意されている

コンテナで稼働中のサービス例

• スーパールート探索サービス
• サーバーでルート探索
• 5種類のコンテナの組み合わせで実現
• 処理量が多いため、システム負荷が大きい

• マイカーシークサービス

• 車の現在位置や停車位置がスマホから見れる
• 2種類のコンテナの組み合わせで実現
• アクセスは多いが一回あたりの処理量は少ない

実際に本番運用してみて見えてきたこと

• 一般的に言われるコンテナ、Kubernetesのメリットが得られた
• 気軽にAPIを作れる
• テストが簡単
• 運用も簡単
• もっとやりたいことが出来て、やりたくないことをしなくていい仕組みへ
• SaaSやマネージドサービスを使いたい
• 自動化できるポイントはとことん自動化する

なぜAWSなのか？

• コンテナ環境だけでなく、その他の環境も含めて使いやすいことを意識した
• サービスが長くサポートされる
• 豊富なドキュメント、技術サポート

システム構成 CI/CD

• ソースコード、マニフェストファイルはGitHubにのせる
• CodePipeline、CodeBuild、ECRの流れ
• ArgoCDによってGitOpsを実現

システム構成 インフラ

• TerraformとCfnの併用
• コードベースで管理

組織もDevOps的に

• アプリケーションの実装に集中

移行をやってみた

• 元がk8sだったこともありコンテナで作られた環境を移行すること自体は簡単だった
• AWSの基本的な知識は勉強が必要
• 研修などを活用

移行をやってみた マイカーシークサービスの移行例

• 車両の位置情報をPostgreに保存
• 先にAWS環境を構築
• 先にデータのみAWSに転送・同期
• DBをDynamoDBに変更

苦労した点

API GatewayとEKSをプライベートに組み合わせたい 色々試した結果、Nginx Ingress Controllerを使う形に落ち着く

Amazon SageMakerによる画像データ利用の改善

画像収集・共有サービス

• リアルタイム画像共有サービス
• ドライブレコーダー画像をサーバーで共有し、行き先の状況を実写で確認
• 蓄積データ量は約1.5億枚
• BigDataで撮影対象を選定
• 不適切画像のフィルタ、プライバシー処理を受信サーバー側でSageMakerによる実施

YOLOv3 (object Detection)

• CNNを用いたオープンソースの物体検出アルゴリズム
• 速度・精度の面で他のアルゴリズムより優れている

SageMaker導入前の開発環境

• S3とEC2上のDockerコンテナ

導入前の課題

• システム管理の煩雑さ
• リソースや環境を自分で構築管理しなければならない
• 無駄なコストの発生
• インスタンス・GPUの並列化実装が難しい
• トレーニング時以外のGPUの消費
• 本番利用の難しさ

SageMaker導入後のAI開発プロセス

• Notebook instance
• Training
• Deploy を別々のインスタンスで実施

SageMaker導入後に実現できたこと

• システム管理の煩雑さからの脱却
• SageMakerによる開発プロセスの効率化
• コスト削減
• マルチインスタンス・マルチGPU対応
• トレーニングコストを3割以上カット
• 本番利用に役立つ機能

MXNet/Gluon YOLOv3

• GluonCV
• 公式サイトで最新の状態にメンテナンスされた多様なモデル
• 簡単にモデルを利用ことができる充実したライブラリ
• MXNet/Gluon

プライバシーフィルタAIによる処理結果

• SageMakerでの処理は、マスク部分の削減（ナンバープレートだけ）になった

まとめ

• アプリケーションリリースサイクルの短縮
• 環境に依存したソースコード　EKS+Kustomizeの導入
• 開発と運用の分離 DevOpsの導入
• お客様へ提供できる価値の明確化 デジタルイノベーションプログラム活用
• サービスを駆動させるためのモデルデータの継続的な更新

今後の展望

• 年内にプラットフォームの商用稼働予定
• Amazon SageMaker Neoの導入
• 理論速度の高速化とホスティング環境のインスタンスタイプを下げることによるコスト削減
• EKSでのサービスメッシュ対応
• DevSecOpsへ取り組む

感想

EKSやSageMakerを利用することで、システム管理の煩雑さからの解放、無駄なコストの削減、DevOpsの導入と改善が進んでいるようでした。

また、SageMakerを利用することで画像収集・共有サービスのクオリティも上がっているとのことで興味深いセッションでした。